Некоторое время назад мы писали про обработку гипервизором VMware vSphere таких состояний хранилища ВМ, как APD (All Paths Down) и PDL (Permanent Device Loss). Вкратце: APD - это когда хост-сервер ESXi не может получить доступ к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды, а PDL - это когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось.
Так вот, в новой версии VMware vSphere 6.0 появился механизм VM Component Protection (VMCP), который позволяет обрабатывать эти ситуации со стороны кластера высокой доступности VMware HA в том случае, если в нем остались другие хосты, имеющие доступ к виртуальной машине, оставшейся без "хост-хозяина".
Для того чтобы это начало работать, нужно на уровне кластера включить настройку "Protect against Storage Connectivity Loss":
Далее посмотрим на настройки механизма Virtual Machine Monitoring, куда входят и настройки VM Component Protection (VMCP):
С ситуацией PDL все понятно - хост больше не имеет доступа к виртуальной машине, и массив знает об этом, то есть вернул серверу ESXi соответствующий статус - в этом случае разумно выключить процесс машины на данном хосте и запустить ВМ на других серверах. Тут выполняется действие, указанное в поле Response for a Datastore with Permanent Device Loss (PDL).
Со статусом же APD все происходит несколько иначе. Поскольку в этом состоянии мы не знаем пропал ли доступ к хранилищу ВМ ненадолго или же навсегда, происходит все следующим образом:
возникает пауза до 140 секунд, во время которой хост пытается восстановить соединение с хранилищем
если связь не восстановлена, хост помечает датастор как недоступный по причине APD Timout
далее VMware HA включает счетчик времени, который длится ровно столько, сколько указано в поле Delay for VM failover for APD (по умолчанию - 3 минуты)
по истечении этого времени начинается выполнение действия Response for a Datastore with All Paths Down (APD), а само хранилище помечается как утраченное (NO_Connect)
У такого механизма работы есть следующие особенности:
VMCP не поддерживает датасторы Virtual SAN - они будут просто игнорироваться.
VMCP не поддерживает Fault Tolerance. Машины, защищенные этой технологией, будут получать перекрывающую настройку не использовать VMCP.
Для тех из вас, кто не смог виртуально присутствовать на ивенте, доступна полноценная запись сессий форума:
Среди докладов и сессий вопросов и ответов можно найти актуальную информацию о различных продуктах VMware, таких как vSphere, VSAN, NSX, vRealize Operations, Horizon View и других.
Приятно, что интерфейс доступа к материалам сделали в интерактивном формате, а не скучным списком записанных сессий. Запись доступна для всех желающих после простой регистрации.
Мы уже упоминали компанию opvizor на нашем сайте - она тогда называлась еще Icomasoft. Она время от времени делает утилитки для виртуальной инфраструктуры. Оказалось у нее есть могущая оказаться полезной многим утилита Snapwatcher Enterprise Edition.
Как знают администраторы VMware vSphere, снапшоты виртуальных машин в большой виртуальной инфраструктуре - это просто беда. Они плодятся неаккуратными пользователями и администраторами, создаются пачками в тестовых системах и почему-то иногда не удаляются средствами резервного копирования. Для решения таких проблем и предлагается использовать Snapwatcher:
Что умеет Snapwatcher:
Отслеживание имеющихся снапшотов ВМ на различных vCenter.
Отчет о количестве паразитно занятого снапшотами дискового пространства.
Нахождение некорректных снапшотов (например, после средств бэкапа).
Удаление ненужных снапшотов централизованно, из одной консоли.
Починка невалидных снапшотов (очевидно, работает не всегда - но весьма интересная функция).
Отслеживание истории снапшотов.
Как это работает:
Сам продукт Snapwatcher платный ($200 за лицензию на пользователя), но у него есть триальная версия. А так как в большинстве случаев проблема со снапшотами в виртуальной среде - разовая, то можно скачать Snapwatcher бесплатно и все пофиксить.
Компания VMware довольно оперативно выставила на всеобщее обсуждение бета-версию своего основного руководства по обеспечению информационной безопасности виртуальной инфраструктуры vSphere 6.0 Hardening Guide.
В этой Excel-табличке на данный момент общим списком собраны основные рекомендации (подчеркнем, что список неполный, и в релизной версии рекомендаций будет больше). Часть рекомендаций была удалена из руководства или перемещена в документацию - список этих пунктов приведен вот тут.
Основное, что ушло из руководства - это операционные рекомендации, то есть что следует делать правильно во время эксплуатации VMware vSphere. Это переместилось в соответствующие разделы документации по платформе. В итоге, осталась сухая выжимка из необходимых настроек безопасности, которые нужно правильно применять в своей инфраструктуре.
Гайдлайны сгруппированы в профили риска (Risk Profiles) - их всего три штуки (1, 2, 3), и они определяют степень критичности их применения. Уровень 1 - только для высокозащищенных систем, 2 - для окружений с чувствительными данными (например, персональными), 3 - для обычных производственных систем.
Также прибавились префиксы компонентов для рекомендаций:
Было: enable-ad-auth
Стало: ESXi.enable-ad-auth
Кстати, интересное видео о том, как нужно использовать Hardening Guide:
Компания VMware с радостью примет пожелания и замечания к руководству, которые можно оставить вот тут. Релиз финальной версии VMware vSphere 6.0 Hardening Guide ожидается во втором квартале 2015 года.
Не так давно мы писали про технологию Virtual Volumes (VVols), которая полноценно была запущена в новой версии платформы виртуализации VMware vSphere 6. VVols - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее.
VVols - это один из типов хранилищ (Datastore) в vSphere:
Тома vVOLs создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы сейчас видите в папке с ВМ, создается отдельный vVOL.
Многие администраторы задаются вопросом: а почему VVols - это крутая штука, нужны ли они вообще? VMware в своем блоге отвечает на этот вопрос. Попробуем изложить их позицию здесь вкратце.
Ну, во-первых, VVols дают возможность создавать аппаратные снапшоты, клоны и снапклоны на уровне одной виртуальной машины, а не целых LUN, но это неконцептуально. Вопрос следует понимать глубже.
Все идет из концепции SDDC (Software Defined Datacenter), которая подразумевает абстракцию всех уровней аппаратных компонентов (вычислительные ресурсы, сети, хранилища) на программный уровень таким образом, чтобы администратор виртуальных ресурсов не ломал себе голову насчет физического устройства датацентра при развертывании новых систем. Иными словами, при создании виртуальной машины администратор должен определить требования к виртуальной машине в виде политики (например система Tier 1), а программно-определяемый датацентр сам решит где и как эту машину разместить (хост+хранилище) и подключить ее к сети (тут вспомним про продукт VMware NSX).
С точки зрения хранилищ (SDS - software defined storage) эта концепция реализуется через подход Storage Policy Based Management (SPBM), предполагающий развертывание новых систем на хранилищах, которые описаны политиками. Этого мы уже касались в статье "VMware vSphere Storage DRS и Profile Driven Storage - что это такое и как работает".
Если раньше дисковый массив определял возможности хранилища, на котором размещалась ВМ (через LUN для Datastore), и машина довольствовалась тем, что есть, то теперь подход изменился: с Virtual Volumes, к которым привязаны политики виртуальных машин, сама машина "рассказывает" о своих требованиях дисковому массиву, который уже ищет, где он может ее "поселить". Этот подход является более правильным с точки зрения автоматизации и человеческого фактора (ниже расскажем почему).
Представим, что у нас есть три фактора, которые определяют качество хранилища:
Тип избыточности и размещения данных (например, RAID - Stripe/Mirror)
Наличие дедупликации (да/нет)
Тип носителя (Flash/SAS/SATA)
Это нам даст 12 возможных комбинаций типов LUN, которые мы можем создать на дисковом массиве:
Соответственно, чтобы учесть все такие комбинации требований при создании виртуальных хранилищ (Datastores), мы должны были бы создать 12 LUN. Но на этом проблемы только начинаются, так как администратор всегда стремится выбрать лучшее с его точки зрения доступное хранилище, что может привести к тому, что LUN1 у нас будет заполнен под завязку системами разной критичности, а новые критичные системы придется размещать на LUN более низкого качества.
На помощь тут приходят политики хранилищ (VM Storage Policies). Например, мы создаем политики Platinum, Silver и Gold, для которых определяем необходимые поддерживаемые хранилищами функции, которые обоснованы, например, критичностью систем:
Если говорить о примере выше, то Platinum - это, например, хранилище с характеристиками LUN типов 1 и 3.
Интерфейс vSphere Web Client нам сразу показывает совместимые и несовместимые с этими политиками хранилища:
Так вот при развертывании новой ВМ администратору должно быть более-менее неважно, на каком именно массиве или LUN будет расположена машина, он должен будет просто выбрать политику, которая отражает его требования к хранилищу. Удобно же!
При создании политики администратор просто выбирает провайдера сервисов хранения (в данном случае массив NetApp с поддержкой VVols) и определяет необходимые поддерживаемые фичи для набора правил в политике:
После этого при развертывании новой виртуальной машины администратор просто выбирает нужную политику, зная обеспечиваемый ей уровень обслуживания, и хранилищем запускается процесс поиска места для новой ВМ (а точнее, ее объектов) в соответствии с определенными в политике требованиями. Если эти требования возможно обеспечить, то создаются необходимые тома VVOls (как бы отдельные LUN для объектов машины). Таким образом, с помощью политик машины автоматически "вселяются" в пространство хранения дисковых массивов в соответствии с требованиями, не позволяя субъективному человеку дисбалансировать распределение машин по хранилищам различных ярусов. Вот тут и устраняется человеческий фактор, и проявляется сервисно-ориентированный подход: не машину "селят" куда скажет дядя-админ, а система выбирает хранилище для ВМ, которое соответсвует ее требованиям.
Вскоре после выхода платформы виртуализации VMware vSphere 6.0 компания VMware выпустила апрельский патч VMware ESXi 6.0 (Build 2615704). Обновление ESXi600-201504001 описано в KB 2111975. В данном билде есть только исправления багов, его статус - Critical.
Какие ошибки были исправлены:
Выпадение в "розовый экран смерти" при промотке логов хоста через прямое подключение к консоли сервера - DCUI (по комбинации клавиш ALT+F12).
Stateless-хосты VMware ESXi (бездисковые, загруженные в память) могут упасть при применении профиля из VMware Host Profiles (с ошибкой A specified parameter was not correct: dvsName).
Производительность виртуальной машины с ОС Windows, для которой включена технология Fault Tolerance, может неожиданно сильно упасть.
Баг с непредоставлением сервером vCenter лицензии stateless-хосту.
Когда у вас много виртуальных машин с небольшой памятью (< 128 МБ), в процессе NUMA remapping может выскочить "розовый экран смерти".
Как мы видим, баги в ESXi 6.0 еще есть, и пока некуда торопиться с обновлением с версий 5.x.
Скачать апрельский патч VMware ESXi 6.0 (Build 2615704) можно с VMware Patch Portal, введя номер билда в поиск.
Как мы видим, за 7 лет размер вырос не катастрофически - всего в три раза. Посмотрите на продукты других вендоров и поймете, что это не так уж и много.
На диаграмме:
Как автор вычислял размер гипервизора? Он сравнил размер следующих пакетов, содержащих в себе компоненты ESXi:
Пакет "image" в ESXi 3.5
Пакет "firmware" в ESXi 4.x
VIB-пакет "esx-base" в ESXi 5.x и 6.x
Табличка размеров гипервизора для всех версий (не только мажорных):
ESXi
Size
4.0
57,80 MB
4.0 U1
58,82 MB
4.0 U2
59,11 MB
4.0 U3
59,72 MB
4.0 U4
59,97 MB
4.0 LATEST
59,99 MB
4.1
85,45 MB
4.1 U1
85,89 MB
4.1 U2
85,25 MB
4.1 U3
85,27 MB
4.1 LATEST
85,19 MB
5.0
133,64 MB
5.0 U1
132,32 MB
5.0 U2
132,27 MB
5.0 U3
132,56 MB
5.0 LATEST
132,75 MB
5.1
124,60 MB
5.1 U1
124,88 MB
5.1 U2
125,67 MB
5.1 U3
125,85 MB
5.1 LATEST
125,85 MB
5.5
151,52 MB
5.5 U1
152,24 MB
5.5 U2
151,71 MB
5.5 LATEST
151,98 MB
6.0
154,90 MB
Но почему ISO-образ ESXi 6.0 занимает 344 МБ, а не 155 МБ? Потому что есть еще пакет VMware Tools для различных гостевых ОС (а их поддерживается очень много) плюс драйверы устройств серверов.
Многие из вас знают, что компания Veeam в конце прошлого года выпустила лучший продукт для резервного копирования и репликации виртуальных машин Veeam Backup and Replication 8. Многие пользователи спрашивают, есть ли руководство по этому продукту на русском языке. Оказывается, есть, и об этом рассказал Владимир Ескин.
Как многие из вас знают, одной из новых возможностей VMware vSphere 6.0 в плане хранилищ стала новая архитектура Virtual Volumes (VVols). VVols - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Тома VVols создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы видите в папке с ВМ, создается отдельный VVol.
Между тем, поскольку технология VVol на сегодняшний день находится в первой своей релизной версии, а продуктов у VMware очень много, на сайте VMware появился список продуктов (в пункте 1 выберите Virtual Volumes), с которыми VVols работают, и тех, где поддержка еще не заявляена.
В целом можно сказать, что внедрять VVols в производственной среде полноценно пока рано, первая версия технологии предназначена скорее для тестирования и пробной эксплуатации с отдельными системами предприятия.
Продукты и технологии, которые поддерживают Virtual Volumes (VVols):
Продукты VMware:
VMware vSphere 6.0.
VMware vRealize Automation 6.2.
VMware Horizon 6.1.
VMware vSphere Replication 6.0
VMware NSX for vSphere 6.x
Возможности платформы VMware vSphere 6.0:
Storage Policy Based Management (SPBM)
Thin Provisioning
Linked Clones
Native Snapshots
View Storage Accelerator also known as Content Based Read Cache (CBRC)
Storage vMotion
vSphere Flash Read Cache
Virtual SAN (VSAN)
vSphere Auto Deploy
High Availability (HA)
vMotion
xvMotion
vSphere Software Development Kit (SDK)
NFS version 3.x
Продукты и технологии, которые НЕ поддерживают Virtual Volumes (VVols):
Продукты VMware:
VMware vRealize Operations Manager 6.x
VMware vCloud Air
VMware Site Recovery Manager 5.x to 6.x
VMware vSphere Data Protection 5.x to 6.x
VMware Data Recovery 2.x
VMware vCloud Director 5.x
Возможности VMware vSphere 6.0:
Storage I/O Control
NFS version 4.1
IPv6
Storage Distributed Resource Scheduler (SDRS)
Fault Tolerance (FT) + SMP-FT
vSphere API for I/O Filtering (VAIO)
Array-based replication
Raw Device Mapping (RDM)
Microsoft Failover Clustering (MSCS)
Отслеживать официальную поддержку VVols со стороны продуктов и технологий VMware можно в специальной KB 2112039. Там же, кстати, находится и полезный FAQ.
Для поиска совместимого с технологией VVols оборудования необходимо использовать VMware Compatibility Guide:
Ранее смену сертификатов на vCSA необходимо было делать из командной строки, что очень неудобно и требует времени. Теперь это можно сделать за пару минут с помощью данной утилиты, пользоваться которой очень просто.
Для начала работы вам понадобится Windows-машина (Windows 7, Server 2008 R2) с установленным Java SE Runtime Environment 8. Также потребуется некоторым образом подготовить окружение, о чем написано вот тут (вкладка Instructions).
Возможности Certificate Manager for vCenter Server Appliance 5.5:
Замена сертификатов для vCenter Server, Inventory Service, Log Browzer и Auto Deploy.
Поддержка сервиса Single-Sign On (SSO), который использует тот же сертификат, что и vCenter Server.
Возможность создания резервных копий предыдущих сертификатов и ассоциированных с ними файлов.
Логгирование процесса и возможность анализа логов.
Как пользоваться утилитой:
Запускаем certmgr.jar.
Выбираем компоненты vCSA, для которых нужно заменить сертификаты.
Вводим параметры учетной записи root на vCSA.
Вводим параметры учетной записи vCenter Single-Sign On (в качестве пользователя нужно брать только Administrator@vsphere.local, а в поле IP/Hostname нужно вводить FQDN-имя хоста).
С помощью drag and drop перетащите сертификат, ключ и pfx-файл в соответствующие текстовые поля.
Нажмите кнопку Start и дождитесь появления сообщения Run Complete.
Нажмите на кнопку Logs, чтобы узнать, успешно ли завершилась процедура замены сертификатов.
Скачать Certificate Manager for vCenter Server Appliance 5.5 можно по этой ссылке. Ожидаем в скором времени версию с поддержкой vSphere 6 и vCSA 6.
До VMworld еще 7 месяцев и сейчас в сфере виртуализации межсезонье. Поэтому 15 апреля компания VMware решила провести бесплатное онлайн-мероприятие VMware Online Technology Forum, принять участие в котором может любой желающий.
На форуме будут следующие активности:
Прямой эфир с техническими экспертами VMware, где можно будет задавать вопросы онлайн. На ивенте будут такие знаменитости, как Joe Baguley, Duncan Epping и Mike Laverick.
Множество лабораторных работ и лекций по следующим темам:
В последнее время мы много пишем о новой версии платформы виртуализации VMware vSphere 6.0, о которой большинство блоггеров писало еще со времени выпуска бета-версии. Как раз по этой причине в сети размещено много статей, относящихся к бете и ее возможностям, что иногда не соответствует параметрам и функционалу релизной версии. Попробуем в этой статье внести определенность в некоторые из этих вещей.
Итак, что есть на самом деле в VMware vSphere 6:
Первая ошибка была в документе vSphere 6.0 What's New - там было указано, что в кластере может быть до 6000 виртуальных машин. На самом деле их может быть до 8000.
Если раньше толстым клиентом vSphere Client (C#) можно было соединяться только с хостами ESXi, то в релизной версии можно коннектиться и к vCenter Server. Однако помните, что функции, которые появились, начиная с версии vSphere 5.5, доступны только в тонком клиенте vSphere Web Client. Толстым клиентом можно редактировать функции доступные до Virtual Hardware 8 (например, добавить памяти или диск выключенному vCenrer), а вот Virtual Hardware 9, 10 и 11 - уже доступны только для чтения.
Fautl Tolerance с несколькими vCPU будет доступна для машин vCenter, но только для некоторых вариантов использования. Информация об этом появится несколько позже.
Поддерживаемые БД vCenter для Windows включают в себя Microsoft SQL Server 2008 R2, 2012 и 2014, Oracle 11g и 12c, а также встроенную БД vPostgres. БД vPostgres для Windows имеет ограничение 20 хостов и 200 виртуальных машин. При апгрейдах инфраструктур, где была БД SQL Express, будет установлен vPostgres. vCenter Server Appliance (vCSA) поддерживает встроенную БД vPostgres для 1000 хостов и 10,000 виртуальных машин (то есть, на полноценную конфигурацию). Также для vCSA поддерживаются Oracle 11g и 12c, но их поддержка в скором времени будет прекращена (только для vCSA, само собой).
По поводу кластеров vCenter средствами MSCS - да, Cluster Services поддерживаются для vCenter Server 5.5 U3 и 6.0, в дополнение к кластерам БД на бэкэнде.
Если для ранних билдов vSphere политику RPO для vSphere Replication можно было понизить до 5 минут, то в релизной версии минимум - 15 минут.
По поводу нового компонента Platform Services Controller (PSC), который включает в себя модули Single Sign-On (SSO), Licensing и VMware Certificate Authority (VMCA) - его надо выносить на отдельную машину тогда, когда у вас есть несколько решений, использующих SSO, например vSphere и vRealize Suite. В остальных случаях для малых и средних инфраструктур ставьте вместе с vCenter.
В версии vSphere 6.0 все компоненты vSphere Web Client, Inventory Service, Auto-Deploy, Syslog Collector, Network dump collector и некоторые другие ставятся только на один сервер с vCenter Server. Если вы обновляете инфраструктуру vSphere 5.x на 6.x, то конфигурация компонентов будет собрана со всех серверов, где они установлены, но сами компоненты будут поставлены на один сервер.
Многие из вас уже подумывают об обновлении своей виртуальной инфраструктуры на новую версию платформы VMware vSphere 6 (см. тут о том, стоит ли обновлять). Основное препятствие к обновлению на сегодняшний день - неподдержка средствами резервного копирования новой версии vSphere 6.0 и, в частности: технологии VVols.
Например, компания Veeam, выпускающая продукт номер 1 для резервного копирования виртуальных машин Veeam Backup and Replication, не рекомендует обновляться сейчас и просит подождать до конца апреля, когда будет выпущена версия VeeamBackup & Replication 8.0 Update 2:
Со своей же стороны компания VMware выпустила полезную KB, где перечислены основные моменты по апгрейду компонентов инфраструктуры vSphere 6.0. Поэтому если проблема резервного копирования в ESXi 6.0 вас не пугает - можно стартовать апгрейд, предварительно изучив материалы ниже.
Во-первых, полезная табличка по последовательности обновления компонентов и соответствующая KB:
List of recommended topologies for vSphere 6.0.x (2108548)
Unable to find the vCenter Server 6.0 Appliance OVA, OVF, ZIP, or VMDK files on the VMware download page (2110730)
Upgrading to vCenter Server 6.0 best practices (2109772)
В-третьих, нужно посмотреть статьи о миграции базы данных vCenter:
Migrating the vCenter Server database from SQL Express to full SQL Server (1028601)
Upgrading to vCenter Server 6.0 without migrating SQL database to vPostgres (2109321)
В-четвертых, необходимо изучить, как происходит работа с сертификатами в vSphere 6.0:
Implementing CA signed SSL certificates in vSphere 6.0 (2111219)
В-пятых, посмотрите рекомендации по отдельным продуктам, если они есть в вашей виртуальной инфраструктуре, например:
vCenter Server (Windows):
Upgrading to Windows vCenter Server 6.0 causes python.exe to fail (2110912)
Installing or Upgrading to vCenter Server 6.0 fails with the error: Incompatible MSSQL version with vCenter Server 6.0 (2111541)
vCenter Server Appliance:
Upgrading the vCenter Server Appliance to vSphere 6.0 with embedded Postgres hangs on Starting VMware vCenter Server (2110080)
Installing or upgrading vCenter Server Appliance to vSphere 6.0 fails with the error: Error while configuring vSphere Auto Deploy Waiter firstboot. (2110025)
vRealize Automation:
Unable to edit a tenant created in vRealize Automation with the vCenter 5.5 SSO after upgrading from vCenter SSO 5.5 to PSC (Platform Services Controller) 6.0 (Windows-based SSO only) (2109719)
Reinstalling the VMware vRealize Automation Identity Appliance or vCenter Server SSO makes tenants inaccessible (2081462)
vRealize Operations Manager and vCenter Operations Manager:
The vSphere Web Client 6.0 displays an internal error after upgrading to vSphere 6.0 in a pre-5.8.5 vRealize Operations Manager environment (2111224)
В-шестых, открываете VMware vSphere 6.0 Upgrade Guide - и начинайте, чего тянуть. Вся официальная документация по VMware vSphere 6 размещена тут.
Ну и помните, что если у вас небольшая инфраструктура, и вам не жалко потерять исторические данные (производительность, логи, скрипты), то лучше переустановить VMware vSphere и сопутствующие продукты заново. Это позволит избежать ошибок, связанных именно с апгрейдом (такое часто встречалось в прошлых версиях).
Удивительно, на факт: средство с забавным названием SexiLog представляет собой довольно мощное средство для визуализации (в реальном времени) и анализа логов в среде VMware vSphere, при этом является абсолютно бесплатным (в отличие от VMware Log Insight).
Продукт выполнен в виде готового виртуального модуля (Virtual Appliance) по принципам архитектуры ELK stack (ElasticSearch, Logstash и Kibana). Приятно, что SexiLog поддерживает также и лучшее средство для резервного копирования виртуальных машин Veeam Backup and Replication (мы писали о нем тут):
На выходе администратор получает набор дэшбордов (они называются SexiBoards), которые отражают текущее состояние инфраструктуры по логам в виде 20 преконфигуренных представлений. Их работающие онлайн демо-версии можно увидеть вот тут. Некоторые из них весьма полезны, например, представление vMotion Downtime покажет, сколько система простаивала при кратковременном переключении работы машины с одного на другой хост ESXi.
Если вам не нравятся дефолтные компоненты модуля, то можно его подкорректировать и собрать самостоятельно, используя вот это руководство. Также есть подробный мануал.
SexiLog получает данные из следующих источников:
UDP/514 для протокола syslog - используется со стороны VMware ESXi.
UDP/162 для SNMP - используется как VMware ESXi, так и продуктом Veeam Backup and Replication.
UDP/1514 для логов vCenter в формате json, которые перенаправляются агентом nxlog.
UDP/1515 для Windows eventlog, которые перенаправляются агентом nxlog с машины Windows vCenter (можно смотреть на любую Windows-машину).
Интересная картинка о том, что продукт является полностью бесплатным:
Скачать решение SexiLog и почитать о шагах для быстрого старта можно по этой ссылке.
Как все присутствующие здесь знают, компания VMware недавно выпустила новую версию решения для виртуализации серверов VMware vSphere 6, в которой присутствует огромное количество новых функций.
Но стоит ли делать апгрейд на новую версию прямо сейчас? Давайте попробуем рассмотреть все за и против.
Аспект обновления
Почему стоит обновлять на vSphere 6
Почему не стоит обновлять
Баги
Многие баги, которые вас мучали, теперь исправлены.
Традиционно в новых версиях VMware vSphere 6 могут быть очень серьезные баги, вплоть до нарушения функционирования всей ИТ-инфраструктуры (например, вот). Вы первыми будете наступать на все грабли.
Жизненный цикл поддержки
vSphere 5.0 и 5.1 прекратят поддерживаться (End of General Support) в августе 2016, а
VMware vSphere 6.0 поддерживается аж до марта 2020 (уже люди будут жить на Марсе).
VMware vSphere 5.5 поддерживается до сентября 2018 года. Времени очень много (больше, чем до ЧМ-2018).
Железо и поддерживаемые устройства
Появились новые драйвера (чипсеты, устройства) и список HCL расширен (плюс гостевые ОС), суперновые железки будут работать.
Имейте в виду, что старые железки (2-3 года) исключаются из комплекта драйверов мажорной версии vSphere. Ваше текущее оборудование может быть в этом списке.
Новые фичи
Их действительно много!
Но в основном они для издания vSphere Enterprise Plus (хотя в этот раз даже для Standard что-то перепало).
Лицензии (я уже купил)
Можно купить только VMware vSphere 6.
Но всегда можно сделать даунгрейд лицензий на vSphere 5.1 и 5.5.
Все равно нужен обычный vSphere Client для некоторых задач.
Поддержка системами резервного копирования
Если используете ПО на базе агентов в гостевой ОС - нет проблем.
Если же бэкап на уровне виртуальных машин - нужно проконсультироваться с вендором насчет совместимости с такими новыми функциями как VVOls, новый Fault Tolerance и прочими.
Планируете P2V-миграцию
-
Нужно иметь в виду, что средство переноса физических машин в виртуальные vCenter Converter 6.0 на данный момент недоступно.
Знаете еще причины, по которым не стоит обновляться на vSphere 6? Пишите в каменты!
P.S. Опытные люди говорят, что обновляться до Update 1 нельзя.
Мы не раз писали об утилите RVTools, которая помогает в вопросах администрирования виртуальной инфраструктуры VMware vSphere (конфигурации и аудит). На днях вышло обновление этого средства - RVTools 3.7.
Автор утверждает, что скачано уже более 400 тысяч копий утилиты. Давайте посмотрим, что там появилось нового:
VI SDK поменяно с версии 5.0 на 5.5.
Увеличен таймаут при операции получения данных с 10 до 20 минут для окружений с большим числом хостов.
Новое поле VM Folder на вкладках vCPU, vMemory, vDisk, vPartition, vNetwork, vFloppy, vCD, vSnapshot и vTools.
На вкладке vDisk появилась информация Storage IO Allocation.
На вкладке vHost новые поля: service tag (serial #) и строка OEM-производителя.
На вкладке vNic новое поле: имя (distributed) virtual switch.
На вкладке vMultipath добавлена информация о доступе по нескольким путям.
На вкладке vHealth новая проверка: Multipath operational state (состояние доступа по нескольким путям).
Еще одна новая проверка vHealth: Virtual machine consolidation needed (машины, для которых нужно консолидировать снапшоты).
На вкладке vInfo новые поля: boot options, firmware и Scheduled Hardware Upgrade.
На статус-баре появилась дата и время последнего обновления данных.
На вкладке vHealth ошибки поиска датасторов видны как предупреждения.
Можно экспортировать csv-файлы через интефейс командной строки (как и xls).
Можно установить интервал автообновления данных.
Все время и дата отформатированы в формате yyyy/mm/dd hh:mm:ss.
Папки со временем и датой также создаются в формате yyyy-mm-dd_hh:mm:ss.
Bug fix: на вкладке dvPort теперь отображаются все сети.
Скачать RVTools 3.7 можно по этой ссылке. Документация доступна тут. Молодец автор - столько лет прошло, а утилита продолжает обновляться.
Компания VMware, к сожалению или к счастью, докатилась до уровня Adobe и ей подобных. Вместо человеческих разделов на сайте, где можно скачать что нужно, компания сделала специальный загрузчик своего программного обеспечения - VMware Software Manager - Download Service.
После того как вы установите продукт, откроется веб-страница My VMware, где нужно будет залогиниться:
Ну и дальше можно открыть раздел Datacenter & Cloud Infrastructure, где можно выбрать для скачивания VMware vSphere 6:
Все, в принципе, просто, только не очень понятно зачем.
Новых возможностей VMware vSphere 6.0 так много, что все они не уместятся в одной статье, поэтому приведем тут ссылки на наши заметки с описанием нового функционала платформы:
Как вы все знаете, в ближайшее время ожидается релиз новой версии платформы виртуализации VMware vSphere 6, где будет масса новых возможностей. Помимо, собственно, платформы, компания VMware выпустит также и обновленную версию пакета ПО для создания частного облака предприятия - VMware vCloud Suite 6.0. Не так давно стали известны подробности о составе и условиях лицензирования пакета - попробуем рассказать об этом.
Надо начать с того, что VMware vCloud Suite 6.0 состоит из следующих продуктов (как и прежде, лицензия - на процессоры хост-серверов ESXi):
VMware vCenter Site Recovery Manager - средство управления аварийным восстановлением на основе политик.
VMware vRealize Business - пакет решений для автоматического определения стоимости инфраструктуры и измерения потребления ресурсов.
VMware vRealize Automation - решение для автоматизации управления инфраструктурой и приложениями для сред vSphere на основе политик и в режиме самообслуживания.
VMware vRealize Operations - ПО для интеллектуального управления производительностью (мониторинг), ресурсами и конфигурациями.
Напомним, что о решениях семейства vRealize мы писали вот тут и тут, а также тут. Под брендом vRealize компания VMware объединяет все решения, предназначенные для управления гибридной инфраструктурой, в том числе средства управления ресурсами на стороне облачных провайдеров (не только VMware), а также средства управления инфраструктурами на базе различных гипервизоров.
Те, кто читал нашу статью о составе пакета VMware vCloud Suite 5.8, помнят, что в нем были две вещи, которые пропали в версии 6.0:
Теперь во все издания vCloud Suite входит решение vRealize Automation (имя издания соответствует изданию vCloud Suite), а в издания vCloud Suite Advanced и Enterprise - решение vRealize Business Standard:
Давайте посмотрим на возможности vRealize Business Standard в сравнениями с более продвинутыми изданиями этого решения (кликабельно):
Ранее vRealize Business Standard назывался IT Business Management Suite, и о нем мы немного писали вот тут. Это решение нужно для биллинга в виртуальной среде, когда вы знаете почасовую стоимость ваших ресурсов (старички помнят его еще как продукт vCenter Chargeback). С тех пор он весьма неплохо нарастил функционал.
vCenter Networking and Security (vCNS) - это решение также пропало из состава пакета VMware vCloud Suite 6.0. Когда-то vCNS был универсальным решением по обеспечению безопасности для платформы vSphere 5.1 и облачной инфраструктуры под управлением vCloud Director. Теперь же его функции взяла на себя и расширила платформа VMware NSX (она не входит в состав пакета и приобретается отдельно - но со скидкой для пользователей vCloud Suite).
Многих интересует вопрос - в связи с тем что vCNS снимается с продаж, будет ли возможность развертывать интерфейс безопасности vShield Endpoint? Ответ прост - vShield Endpoint является функцией vSphere. Будет возможность скачать и использовать vShield Manager / vCNS Manager только для установки и администрирования vShield Endpoint. Его функции будут лицензироваться ключом к vSphere. Другие функции vCNS будут недоступны.
Что касается состава пакета и лицензирования - на этом все. В следующих заметках мы расскажем о новых функциях компонентов, как станут известны подробности. Добавим, что есть документ на русском языке "VMware vCloud Suite 6.0 - Лицензирование, цены и комплектация", в котором приведено некоторое количество дополнительной информации о данном пакете продуктов.
Продолжаем рассказывать о новых возможностях платформы виртуализации VMware vSphere 6, выход которой ожидается в самое ближайшее время. Сегодня мы расскажем о поддержке режима vGPU, который позволяет предоставить ресурсы видеокарты (GPU) напрямую сразу нескольким виртуальным машинам (режим vGPU). Напомним, что эта технология уже довольно давно поддерживается в продуктах Citrix (а также в решении RemoteFX от Microsoft), а ее поддержка в платформах VMware была анонсирована в прошлом году на VMworld 2014.
Технология vGPU от NVIDIA при использовании с продуктами VMware подразумевает использование в качестве платформы VMware vSphere 6, а в качестве средства управления виртуальными ПК - VMware Horizon 6 (для этого выйдет специальное обновление с версией 6.1).
vGPU поддерживается для графических адаптеров NVIDIA GRID K1 и K2, для каждой из которых определены 4 профиля для виртуальных ПК, которые используют ресурсы видеокарты. Вот таблица этих профилей:
Всего есть три типа пользователей:
Designer - человек, который использует очень требовательные к графическим ресурсам приложения (не только дизайнеры, но и пользователи CAD-приложений).
Power User - человек, использующий подобные приложения время от времени.
Knowledge Worker - пользователь со сравнительно небольшой нагрузкой на ресурсы видеокарты.
Важно, что в рамках одного физического GPU видеокарты можно использовать только профили одного типа. Взгляните на картинку - как можно, а как нельзя:
Опишем здесь вкратце процедуру настройки использования vGPU с VMware vSphere 6, которая приведена в vGPU Deployment Guide (документ еще не вышел).
Для настройки vGPU необходимы следующие компоненты:
VMware vCenter 6.0
VMware ESXi 6.0
VMware Horizon View 6.1
NVIDIA GRID vGPU Manager
Потребуются также настройки BIOS на серверах (для каждого вендора свои). Вот, например, конфигурация Cisco:
CPU Performance: выставить в Enterprise или High Throughput.
Energy Performance: выставить в Performance.
PCI Configuration: выставить MMCFG BASE в 2 GB и Memory Mapped I/O above 4GB: Disabled.
VGA Priority: выставить в Onboard VGA Primary.
Далее нужно развернуть на хостах компонент NVIDIA vGPU Manager, который создает связь между GPU видеокарты и виртуальной машиной. Устанавливается он как обычный VIB-пакет:
После того, как NVIDIA vGPU Manager настроен на хост-серверах ESXi, нужно подготовить виртуальные машины. Делается это через vSphere Web Client. Выберем аппаратные характеристики ВМ в зависимости от типа рабочей нагрузки:
Затем в настройках ВМ нужно добавить Shared PCI Device:
Выбираем тип NVIDIA GRID vGPU и профиль в соответствии с таблицей, приведенной в начале статьи:
Обратите внимание, что нужно зарезервировать память для виртуальных машин, иначе их просто нельзя будет запустить. То есть, кнопку "Reserve all memory" нужно нажать обязательно. Кроме того, для машин, использующих vGPU, не поддерживаются такие технологии как vMotion, HA, снапшоты - то есть, машина полностью привязана к хосту ESXi.
После этого в виртуальном ПК можно устанавливать гостевую ОС (поддерживается Windows 7 и более поздние версии). Затем нужно установить NVIDIA GRID driver (после этого неплохо бы сделать из такой машины шаблон для дальнейшего ускоренного развертывания новых десктопов):
Кстати, в диспетчере устройств в гостевой ОС виртуального ПК можно посмотреть на драйвер графического адаптера:
Затем нужно соответствующим образом настроить пул виртуальных ПК в VMware Horizon View. Просто указываем протокол PCoIP и тип 3D-рендера NVIDIA GRID VGPU:
Вот, в принципе, и все. После этого виртуальные машины готовы к работе с vGPU в рамках пула виртуальных ПК.
Продолжаем рассказывать о новых функциях платформы виртуализации vSphere 6.0 (для этого у нас есть специальная страница). Сегодня у нас на очереди функции сжатия данных в VMware vSphere Replication 6.0. Функция репликации включена во все издания VMware vSphere, начиная с Essentials Plus (то есть, за бортом только Essentials). Кстати, родственная репликации функция резервного копирования VMware Data Protection 6.0 также есть во всех изданиях, начиная с Essentials Plus.
Начнем с того, что vSphere Replication 6.0 полностью совместима с продуктами VMware Virtual SAN 6.0 и vCenter Site Recovery Manager (SRM). Также в vSphere 6.0 появилась функция сжатия данных сетевого трафика при передаче:
Это снижает требования к ширине канала репликации, что особенно актуально при использовании продукта VMware SRM для обеспечения отказоустойчивости на уровне помещений или датацентров. Делается сжатие средствами библиотеки FastLZ, однако сжатие выключено по умолчанию.
При передаче данных репликации пакеты остаются сжатыми до того момента, пока они не отправляются на запись на диск. Но в некоторых случаях, в зависимости от версий ПО и особенностей архитектуры, сжатие может быть не на всем участке пути данных, или его может не быть вовсе. Пример: репликация vSphere 6.0 при соединении с виртуальным модулем vSphere Replication 5.8 - сжатия не будет. Если же, например, данные хоста ESXi 6.0 идут на виртуальный модуль vSphere Replication 6.0, а дальше на хранилище хоста vSphere 5.5, то данные будут разжаты на виртуальном модуле репликации, а дальше пойдут в обычном виде. Отсюда мораль - старайтесь поддерживать актуальные версии своего ПО на всех компонентах инфраструктуры.
В большинстве случаев достигается коэффициент сжатия данных в диапазоне от 1.6 к 1 до 1.8 к 1. Это приводит к уменьшению времени синхронизации и возможности настройки более строгой политики RPO.
Примеры:
1. ВМ с гостевой ОС Windows и диском в 37.5 ГБ при первой репликации без компрессии синхронизируется за 52 минуты. Когда включили компрессию, 20.2 ГБ данных отреплицировалось за 29 минут. Таким образом, эффективное использование канала выросло с 98 Mbps до 177 Mbps.
2. ВМ с гостевой ОС Linux и 4.7 ГБ данных при первичной репликации синхронизировались за 13 минут. После включения компрессии 2,8 ГБ ушли за 8 минут. Эффективное уменьшение ширины канала - с 49 Mbps до 80 Mbps.
Из минусов - компрессия создает нагрузку на процессор, поэтому нужно ее использовать аккуратно, и потому она отключена по умолчанию. Больше информации о технологии репликации от VMware можно найти в документе "VMware vSphere Replication 6.0 Technical Overview".
Интересная штука появилась на сайте проекта VMware Labs - средство миграции VCS to VCVA Converter. Эта штука позволяет преобразовать имеющийся у вас сервер VMware vCenter под управлением ОС Windows с внешней БД Microsoft SQL Server в виртуальный модуль (VIrtual Appliance) vCetner Server Appliance на базе Linux со встроенной базой данных vPostgres, который также должен быть у вас в наличии при миграции.
С помощью утилиты (которая также представляет собой виртуальный модуль) можно перенести саму БД, а также роли, пермиссии, привилегии, сертификаты и службу Inventory Service. Результирующий виртуальный модуль vCSA должен иметь тот же IP-адрес, что исходный сервер VMware vCenter, но не должен быть включен при миграции.
Системные требования VCS to VCVA Converter:
vCenter Server под Windows - для vSphere 5.5 или более поздней версии.
Windows vCenter Server и vCenter Server Appliance должны быть одной версии (например, vCenter Server Windows 5.5 u1 -> VCSA 5.5 u1).
vCenter Server Appliance должен иметь как минимум столько же vCPU и памяти, сколько и исходный хост vCenter Server.
Компоненты vCenter Components (Inventory Service, vSphere Web Client и VMware Single Sign On) должны быть на том же хосте, что и vCenter Server.
Должен быть внешний Microsoft SQL Server 2008 R2 (или более поздний) с vCenter Database (VCDB).
vSphere Web Client Plugins должны быть зарегистрированы под пользователем Active Directory.
Службы VMware Single Sign On (пользователи и группы) на данный момент не переносятся (нужно заводить заново).
Утилита (Migration Appliance) должна иметь возможность взаимодействия с vCenter, его БД и виртуальным модулем vCSA. Следующие порты должны быть открыты на vCenter Server и на VCSA:
22 (ssh)
443 (https)
445 (SMB)
Ограничения утилиты:
Microsoft SQL Server и vCenter Server должны быть на разных хостах (встроенная БД не пойдет).
Microsoft SQL Express Database не поддерживается версией 0.9 утилиты.
Windows Local Users и Groups не мигрируются версией 0.9 утилиты.
vCenter Alarm action scripts также не переносятся в версии 0.9.
Миграция потребует некоторого прерывания в работе vCenter Server.
Конфигурация Linked Mode не мигрируется (надо делать все в ручную).
Сторонние плагины для Web Client (например, VMware Update Manager или NSX) также не будут перенесены.
Загрузить виртуальный модуль VCS to VCVA Converter можно по этой ссылке.
Мы много пишем про новые возможности платформы виртуализации VMware vSphere 6, релиз которой должен состояться уже в ближайшее время. Напомним наши последние посты:
Но и компания VMware тоже старается от нас не отставать. Например, недавно она объявила о доступности вебинара "Новинки vSphere 6" на русском языке, который можно в любое время посмотреть по запросу.
Многовато болтовни в начале, но для тех, кто готов слушать о VMware от VMware - почему бы и нет.
Мы уже немало писали про технологию Transparent Page Sharing (TPS) в VMware vSphere, которая позволяет дедуплицировать страницы оперативной памяти на хост-сервере ESXi при недостатке физической памяти для виртуальных машин. Как мы уже писали тут и тут, в VMware vSphere 5.5 Update 3 и более поздних версиях технология TPS отключена (при дедупликации страниц между машинами), чтобы не нагружать хост понапрасну, поскольку в современных ОС используются большие страницы памяти (Large Memory Pages), вероятность дедупликации которых мала. В то же время, технологию TPS никто из vSphere не убирал, и ее можно в любой момент включить.
Как пишет знаменитый Дункан, В VMware vSphere 5.x есть 4 состояния памяти для хост-сервера относительно параметра minFree:
High (100% от minFree)
Soft (64% от minFree)
Hard (32% от minFree)
Low (16% от minFree)
Эти состояния определяют срабатывание определенных триггеров (об этом ниже). Например, если minFree для вашей конфигурации сервера равно 10 ГБ, то при переходе в состояние, когда занято 6,4 ГБ (Soft), произойдет определенное действие с точки зрения техник оптимизации памяти.
В то же время, триггеры не срабатывают жестко по этим пороговым значениям, а плавно включаются перед ними и плавно выключаются за ними, чтобы не вызвать резких изменений.
Например, при переходе из состояния High в Soft, большие страницы памяти "разламываются" на обычные, чтобы TPS мог их тут же дедуплицировать. Однако, это может сказаться не лучшим образом на производительности - у хоста и так возникает недостаток памяти, а тут еще его нагружают дедупликацией.
Поэтому в VMware vSphere 6.0 ввели новое состояние Clear (100% от minFree), а состояние High переопределили до значения 400% от minFree. Для чего это сделано? А вот для чего.
При недостатке памяти, хостом ESXi используется техника разламывания больших страниц памяти на обычные страницы, которые затем могут быть дедуплицированы с помощью TPS. Это делается затем, чтобы предотвратить свопирование страниц на диск, что является самым тормозным способом освобождения ресурсов. Так вот эта штука начинает активно работать при наличии свободной памяти в промежутке от High (400%) до Clear (100%), чтобы начать работать на еще не испытывающем острого недостатка ресурсов хосте. Но при этом TPS сразу не запускается.
Давайте посмотрим на таблицу:
Состояние памяти (State)
Пороговое значение (% от minFree)
Эффект при переходе в диапазон
High
400%
Большие страницы разламываются на обычные, но TPS не запускается и ждет следующего цикла прохода дедупликации (по умолчанию 60 минут, минимально настраиваемое в расширенном параметре Mem.ShareScanTime время равно 10 минут)
Clear
100%
Разламывание больших страниц и мгновенный запуск TPS
Soft
64%
Включение TPS и техники Memory Ballooning
Hard
32%
Включение TPS, Memory Compression и свопирования на диск
Low
16%
Memory Compression + свопирование на диск + блокировка использования памяти
Это красивое решение - начать разламывать страницы заранее и не нагружать теряющий свободную память хост.
Но все что касается TPS, актуально только тогда, когда TPS включено. По умолчанию же эта техника выключена, а о том, как включить ее, написано вот тут.
Как все из вас знают, скоро выходит обновленная платформа виртуализации VMware vSphere 6, в которой появилась уйма новых возможностей. О многих из них мы уже писали (см, например, нашу последнюю заметку тут). На днях компания VMware сделала еще одну полезную вещь - выложила пошаговые гайды по некоторым компонентам vSphere 6 на сайте VMware Feature Walkthroughs.
Напомним, что про эти гайды мы уже писали тут и тут. Эти штуки позволяют в интерактивном режиме пройти по шагам конфигурации различных продуктов в интерфейсе соответствующего решения. То есть, все так же, как вы будете нажимать в vSphere Web Client:
Какие гайды доступны уже сейчас:
vCenter Server Install - установка компонентов vCenter 6.0. Напомним, что о новых функциях в vCenter мы писали вот тут.
vCenter Server Upgrades - процесс обновления со старых версий vCenter Server, включая 5.x, до версии vCenter 6.0.
vSphere Data Protection – набор пошаговых гайдов, позволяющих пройти весь процесс резервного копирования виртуальных машин. О новых возможностях VDP 6.0 мы также писали вот тут.
vSphere Replication – эти гайды позволят вам самостоятельно настроить репликацию и попробовать повосстанавливать виртуальные машины из реплик.
В ближайшее время ожидаются новые Feature Walkthrough - следите за обновлениями!
Продолжаем рассказывать о возможностях новой версии серверной платформы виртуализации VMware vSphere 6, выход которой ожидается в ближайшее время. Напомним наши последние посты на эту тему:
Сегодня у нас на очереди одна из самых интересных тем в vSphere 6 - технология организации хранилищ VMware vSphere Virtual Volumes (VVOls). Напомним, что ранее мы подробно писали о ней тут. С тех пор появилось некоторое количество новой информации, которую мы постараемся актуализировать и дополнить в этом посте.
Начнем с того, что vVOL - это низкоуровневое хранилище для виртуальных машин, с которым позволены операции на уровне массива по аналогии с теми, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. vVOLs - это новый способ организации хранилищ в виде удобном для массива, когда используется не традиционная файловая система VMFS, а массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин.
Тома vVOLs создаются на дисковом массиве при обращении платформы к новой виртуальной машине (создание, клонирование или снапшот). Для каждой виртуальной машины и ее файлов, которые вы сейчас видите в папке с ВМ, создается отдельный vVOL. В итоге же, создаются следующие тома на хранилище:
1 config vVOL создается для метаданных ВМ, он включает в себя конфигурационный файл .vmx, дескрипторные vmdk для виртуальных дисков, лог-файлы и прочие вспомогательные файлы.
1 vVOL создается для каждого виртуального диска .VMDK.
1 vVOL создается для файла подкачки, если это требуется.
1 vVOL создается для каждого снапшота и для каждого снимка оперативной памяти.
Дополнительные тома vVOL могут быть созданы для клонов или реплик виртуальной машины.
Давайте посмотрим на архитектуру VVols:
Здесь мы видим следующие компоненты:
Storage Provider (SP)
Технология vVOLs при взаимодействии с аппаратным хранилищем реализуется компонентом Storage Provider (SP), который также называется VASA Provider (подробнее об интерфейсе VASA - тут). Storage provider - это предоставляемый вендором аппаратного обеспечения слой ПО, который обеспечивает взаимодействие платформы vSphere и, собственно, хранилища с организованными на нем томами vVOLs в виде контейнеров (storage containers). vVOLs используют механизм VASA 2.0, который позволяет управлять объектами виртуальных машин (дискми) прямо на хранилище.
Protocol EndPoint (PE)
Если раньше каждый хост налаживал в случае необходимости соединение с каждым из vmdk-дисков виртуальных машин и получалось куча связей, то теперь у хранилища есть логическое I/O-устройство, через которое происходит общение с томами vVOL. PE можно считать сущностью, пришедшей на замену LUN, этих PE может быть создано сколько угодно (кстати, длина очереди у PE - 128 по умолчанию, вместо 32 у LUN).
То есть, через PE хост ESXi получает доступ к данным конкретной виртуальной машины. PE совместимы с существующими протоколами FC, iSCSI и NFS и позволяют использовать уже имеющееся ПО для управления путями в SAN. К отдельному PE через vCenter можно привязать или отвязать тома vVOL отдельных виртуальных машин. Для хранилища не нужно много PE, одно это логическое устройство может обслуживать сотни и тысячи виртуальных томов vVOL.
Storage Container (SC)
Это логическая сущность, которая нужна для объединения томов vVOL по типам в целях выполнения административных задач. Storage Container создается и управляется на стороне дискового массива и предназначен для логической группировки и изоляции виртуальных машин (например, виртуальные машины отдельного клиента в публичном облаке vCloud).
vVOL Datastore
Это хранилище, которое непосредственно создается из vSphere Client. По-сути, это представление Storage Container (SC) для платформы VMware vSphere. Этот тип датастора можно, например, выбрать при создании виртуальной машины:
С точки зрения администрирования, эти датасторы аналогичны VMFS-томам - вы так же можете просматривать их содержимое и размещать там виртуальные машины. Но для них недоступны операции расширения или апгрейда - они полностью контролируются со стороны дискового массива.
Policy Based Management
Это механизм, который позволяет назначать виртуальным машинам политики, которые определяют ее размещение, а как следствие, и производительность с точки зрения подсистемы ввода-вывода (например, можно задавать необходимые трешхолды по ReadOPs, WriteOPs, ReadLatency и WriteLatency.).
Дисковый массив на базе этих политик позволяет разместить виртуальную машину на нужном хранилище и обеспечить необходимые операции по обеспечению нужного уровня производительности.
По прочтении этого материала возникает вопрос - а чем vVOLs лучше механизма VAAI, который уже давно существует для VMware vSphere? Ответ прост - это замена VAAI, которая позволяет еще больше функций по работе с виртуальными машинами и организации хранилищ переложить на сторону аппаратного обеспечения. В случае невозможности операций с vVOLs будет произведено переключение на использование примитивов VAAI:
Компания VMware еще с выходом VMware vSphere 5.1 объявила о нескольких новых начинаниях в сфере хранения данных виртуальных машин, включая возможность использования распределенного кеш на SSD-накопителях локальных дисков серверов ESXi. Данная технология имела рабочее название vFlash и находилась в стадии Tech Preview, превратившись позднее в полноценную функцию vSphere Flash Read Cache (vFRC) платформы VMware vSphere 5.5. И это вполне рабочий инструмент, который можно использовать в задачах различного уровня.
Мы уже весьма немало писали про возможности обновленной версии платформы виртуализации VMware vSphere 6, в которой будет настолько много новых фичей, что мы не можем перечислить их все в одной статье. Поэтому мы делаем это по частям:
В этой части мы расскажем о новых возможностях платформы vSphere с точки зрения улучшений, сделанных непосредственно в плане хостов ESXi и виртуальных машин.
Итак, начнем по порядку:
1. Новые возможности хост-сервера и кластера.
Если еще с давних времен кластеры VMware HA/DRS объединяли 32 хоста, то в версии vSphere 6 кластер, наконец-то, может объединять до 64 хостов включительно. Помимо этого, на хосте может быть запущено до 1000 виртуальных машин (и до 8000 в кластере), а сам ESXi поддерживает сервер с числом процессоров до 480 CPU и памятью до 12 ТБ.
Сравним с предыдущей версией:
2. Новые возможности виртуальных машин.
Виртуальные машины, как и хосты ESXi, также стали поддерживать еще большие максимальные конфигурации - теперь можно создать машину со 128 vCPU и до 12 ТБ оперативной памяти:
Интересны также и другие возможности. Горячее добавление памяти теперь правильно работает с vNUMA, что положительно сказывается на производительности. Появилась поддержка ускорения для объектов GDI в пакете драйверов WDDM 1.1, также контроллер xHCI 1.0 теперь работает с драйвером этого контроллера под Мак, начиная с OS X 10.8.
3. vMotion теперь работает между разными vCenter и на большие расстояния.
В VMware vSphere 6 технология горячей миграции виртуальных машин vMotion была значительно улучшена. Во-первых, виртуальные машины могут теперь перемещаться между виртуальными коммутаторами Standard vSwitch и Distributed vSwitch в любой их комбинации, при этом при уходе с vDS настройки машины на его портах сохраняются и уезжают вместе с ней.
Во-вторых, теперь виртуальные машины могут перемещаться между датацентрами с разными серверами vCenter (требуется лишь соединение на уровне L2). При переезде адрес виртуальной машины сохраняется и нарушения функционирования сети не происходит. Настройки машины также уезжают вместе с ней:
MAC-адреса всегда будут уникальными даже на разных vCenter, а когда машина приедет обратно - ее адрес не будет занят.
При этом для миграции не требуется ни общего хранилища, ни той же самой сети или того же vCenter - можно все это в рамках одной операции vMotion поменять:
Кроме того, если раньше vMotion "держала" задержку в канале (RTT) до 10 мс (и до 50 мс в Enterprise Plus издании), то теперь это значение увеличено до 100 мс. То есть, стратегия Follow the sun для перераспределения нагрузки - теперь реальность, так как такое RTT позволяет уже "трансконтинентальные" миграции vMotion:
Интересно, что с помощью такого vMotion можно, например, увести машины из датацентра в местности, где начинается ураган, который все обесточит - и при этом все это будет незаметно для пользователей (почти).
4. Полезные мелочи.
Во-первых, появилась настройка политики сложности пароля в Host Advanced System
Settings. Раньше для этого нужно было мудохаться с pam.d модулем.
Во-вторых, в логах хостов ESXi действия, произведенные через vCenter, включают в себя пользователя, которых их выполнял. Если раньше в логе было так: [user=vpxuser], то теперь вот так: [user=vpxuser:DOMAIN\User]. Весьма удобно.
Улучшенный механизм vSphere Network I/O Control версии 3 позволяет гарантировать уровень обслуживания на уровне vNIC виртуальной машины. Применять NetIOC можно также и к Distributed Port Group:
На этом вкратце все. Ну и так для общей информации - улучшения режима Linked Mode для серверов vCenter:
Продолжаем знакомить наших читателей с новыми возможностями платформы виртуализации VMware vSphere 6, релиз которой должен состояться уже совсем скоро. Напомним наши предыдущие посты на эту тему:
Сегодня у нас на очереди VMware vSphere 6 Web Client. Главная новость как раз об отсутствии нового - веб-клиент, по-прежнему, работает на Flash, никакого HTML5 - и это досадно. Поэтому в комментариях и пишут, что новый клиент - это "lipstick on a pig", то есть косметические улучшения без переработки по существу.
Но есть и хорошая новость - VMware уверяет, что новый клиент работает в пять раз быстрее прошлого:
Посмотрим на тесты:
Действительно, в каких-то отдельных случаях работает в 5 и более раз быстрее. Ну ок, давайте пройдемся по новым фичам:
1. Контроль производительности раздела "All Users’ Tasks".
Если раньше эта штука в панели Recent Tasks грузилась очень долго, особенно в инфраструктурах, где сервер vCenter обслуживал много хостов ESXi и пользователей, то теперь она отключена по умолчанию, чтобы не создавать нагрузки. Включить ее можно вручную, в следующем файле на сервере vCenter:
Для vCenter Server Appliance используйте этот конфиг-файл:
/etc/vmware/vsphere-client/webclient.properties
Меняем строчку show.allusers.tasks=false на show.allusers.tasks=true (перезагрузка не требуется).
Теперь все таски пользователей будут показываться в разделе All Users’ Tasks.
2. Множество улучшений производительности.
Производительность была целью номер один в новой версии vSphere 6 Web Client. Были переработаны следующие разделы:
Страницы Login (в 13 раз быстрее!) и Home
Страницы Summary
Страницы Networking
Списки Related Objects
Общая навигация по разделам
Графики производительности (Performance Charts - в 2 раза быстрее)
Контекстные меню действий по правой кнопке (Action Menu - в 4 раза быстрее!)
3. Таски и гибкое размещение панелей.
Теперь список задач удобно размещен внизу:
Сами панельки можно отлеплять и ресайзить:
4. Реорганизованные Action Menu.
Теперь в меню, вызываемых по правой кнопке, все действия размещены на нужных и интуитивно понятных местах, а сами действия не тянут при прорисовке лишних данных, что увеличивает производительность клиента:
5. Новое меню по кнопке Home.
Теперь из него можно попасть в наиболее часто используемые разделы:
6. Возможность убрать предупреждение о включенном SSH прямо из GUI.
Появилась так давно нужная ссылка Suppress Warning:
7. Возможность поместить алармы и таски на правую панель.
Очень удобно:
8. Ну и гора всяких мелочей.
Типа совместимости с прошлой и новой версией Fault Tolerance:
Самое обидное, что Web Client, по-прежнему, несовместим с VMware Update Manager - можно просматривать его задачи, но запускать Remediate нельзя.
Ну и напоследок полезная ссылка про трюки в vSphere Web Client, вам может оказаться очень полезной - http://tiny.cc/webclientwiki.
Все из вас знают, что недавно компания VMware анонсировала обновленную версию платформы VMware vSphere 6. Ввиду того, что новых функций уж очень много, мы решили разбить описание новых возможностей продуктов серверной линейки на несколько постов. Напомним последние из них:
Сегодня мы поговорим об анонсированной новой версии VMware vSphere Data Protection 6.0 (VDP) - продукте для резервного копирования виртуальных машин на серверах ESXi. Если ранее пользователям предлагалось одно из двух изданий - встроенное в платформу и vSphere Data Protection Advanced (с расширенными функциями), то теперь осталось только одно. Теперь VDP включено во все издания VMware vSphere, кроме самого базового (Essentials). То есть, пользователи vSphere 6.0 Essentials Plus и более старших изданий получат VDP в комплекте. Кстати, продукт vSphere Data Protection Advanced будет недоступен для заказа с 1 марта.
Напомним, что VDP построен на базе решения для резервного копирования и дедупликации EMC Avamar, которое развертывается как готовый виртуальный модуль (Virtual Appliance). ПО работает без агентов, использует функциональность Changed Block Tracking и может восстанавливать не только машины целиком, но и отдельные файлы из бэкапов через браузер. Шестая версия VDP поддерживает до 8 ТБ дедуплицированных данных бэкапов.
Итак, что нового появилось в VDP:
1. Агенты для Microsoft SQL Server, Exchange и SharePoint.
Напомним, что это намного раньше появилось в Veeam Backup and Replication, а теперь VMware "заимствует" функциональность у Veeam. Эти агенты позволяют создавать консистентные копии виртуальных машин с данными приложениями, а также восстанавливать отдельные объекты приложений из бэкапов (например, базу данных или электронное письмо). Агенты поддерживают такие функции, как SQL Server Failover, кластеры AlwaysOn и Exchange Database Availability Groups.
2. В VDP появилась интеграция с хранилищем EMC Data Domain с использованием ПО Data Domain Boost.
Теперь за обработку бэкапов может отвечать Data Domain, а модуль VDP просто отвечать за передачу данных. Данная функция также есть у Veeam.
3. Возможность репликации данных между модулями VDP.
Данные, передаваемые между модулями VDP дедуплицируются, поэтому в канал передаются только уникальные блоки данных. Это может оказаться необходимым при отбрасывании резервных копий на резервные хранилища через WAN. При этом поддерживаются различные топологии репликации данных виртуальных модулей - 1:1, N:1 и 1:N.
4. Сжатие данных для vSphere Replication.
Теперь если вы используете VMware SRM для репликации данных между площадками и восстановления машин после сбоев, то при передаче данных включается технология сжатия данных при передаче (end-to-end network compression).
Типичный коэффициент сжатия данных - от 1.6:1 до 1.8:1. Например, если раньше машина размером 37.5 ГБ передавалась за 52 минуты, то теперь она ужимается до 20.2 ГБ и передается за 29 минут.
5. Улучшенная репликация.
Теперь неаллоцированные регионы данных не гоняются по каналу репликации, что увеличивает ее скорость. Поддерживаются тонкие диски и устройства Virtual SAN.
6. Верификация резервных копий.
Теперь резервные копии VDP можно восстановить на временное хранилище и запустить машины отключенными от сети, чтобы убедиться, что ОС запускается и приложения работают.
7. Поддержка "подмораживания" файловых систем Linux.
Для Windows-систем уже давно есть quiescence-скрипты, которые подмораживают операции с данными ВМ, для которой происходит резервное копирование. Для Linux это появилось в версии VDP 6.0 (функция отключена по умолчанию).
8. Поддержка Storage vMotion и Storage DRS в целевом хранилище.
Ранее при перемещении реплики средствами Storage vMotion требовалась полная ресинхронизация ВМ, а в версии VDP 6.0 перемещение машин между серверами и хранилищами отслеживается, и процесс полной синхронизации не запускается.
Больше подробностей о возможностях vSphere Data Protection 6.0 можно узнать из вот этого документа.